Method for securing data relating to users of a public-key infrastructure

ABSTRACT

The inventive method allows to secure data relating to users of a public key infrastructure who may present certificates ( 11 ) at an institution ( 30 ) in order to initiate transactions. For this purposes the institution ( 30 ) uses and securely stores a secret key or a key pair which is designed for encrypting and decrypting data. Based on an agreement between a certificate holder and the institution ( 30 ), corresponding relational data are generated. Then said relational data are encrypted with the institution&#39;s ( 30 ) secret key or the first key of said key pair. Subsequently the encrypted relational data are integrated into the certificate ( 11 ) which preferably adheres to ITU recommendation X.509 version 3. At a later stage, whenever the certificate holder contacts the institution ( 30 ) in order to initiate a transaction based on said agreement between the certificate holder and the institution ( 30 ), encrypted relational data contained in the certificate ( 11 ) is decrypted by means of the secret key or the second key of said key pair of the institution ( 30 ). Based on the decrypted relational data, data stored in a directory ( 33 ) of the institution ( 30 ) can be verified and the requested transaction be performed.

[0001] The present invention relates to a method for securing datarelating to users of a public key infrastructure according to claim 1.

[0002] The present invention relates in particular to a method forsecuring data which are based on relations between certificate holdersand institutions or closed user groups.

[0003] More particularly the present invention relates to a method forsecuring relational data, based on which, for example, businesstransactions are performed or access to a system may be granted by usingan open, public certificate while privacy of the relations betweencertificate holders and institutions can be maintained.

BACKGROUND OF THE INVENTION

[0004] The emergence of the World wide Web access to the Internet hasbeen accompanied by recent focus on financial transactionvulnerabilities, crypto system weaknesses and privacy issues.Fortunately, technological developments also made a variety of controlsavailable for computer security including tokens, biometric verifiers,encryption, authentication and digital signature techniques usingpreferably asymmetrical public-key approaches (see [1], Richard C. Dorf,THE ELECTRICAL ENGINEERING HANDBOOK, 2nd Edition, CRC-Press, Boca Raton1997, chapter 97, pages 2221-2234 and [7], A. Menezes, P. van Oorschot,S. Vanstone, HANDBOOK OF APPLIED CRYPTOGRAPHY, CRC-Press, Boca Raton1997, chapter 1).

[0005] The basic objectives of encryption are secrecy, authentication(assurance of sender identity to recipient), and digital signatures(authentication plus assurance to sender and third parties that thesignature had not been created by the recipient). This is normallyreferred to as non-repudiation, with further variants such asnon-repudiation of origin, non-repudiation of sending and so on. Offurther importance is integrity which means preventing interference inthe information conveying process.

[0006] Almost all cryptosystems involve publicly known transformationsof information, based on one or more keys, at least one of which is keptsecret. The public-key cryptosystem disclosed 1976 by Diffie and Hellmanis based on two keys, a private-key and a public-key, owned by users ofthis system.

[0007] As described in [2], U.S. Pat. document No. 4,405,829 for the RSAcryptosystem explained below, the public-key cryptosystem providesenciphered communication between arbitrary pairs of people, without thenecessity of their agreeing on an enciphering key beforehand. The Diffieand Hellman system also provides a way of creating for a digitiseddocument a recognizable, unforgeable, document-dependent, digitisedsignature whose authenticity the signer cannot later deny.

[0008] The RSA cryptosystem (named after R. L. Rivest, A. Shamir and L.M. Adleman which in [2] are mentioned as inventors) is the most widelyused public-key cryptosystem. RSA is a commutative transformation, whichallows the private-key and the corresponding public-key to be usedinterchangeably as encryption and decryption keys, thus providingsecrecy and authenticity on a secure channel between two parties A and Bwith no need for additional keys (see [1], pages 2225-2226).

[0009] Since, given only one key of an asymmetric key pair, it ispractically infeasible to determine the other key, an owner A of a keypair may publish his public-key so that anyone can use this public-keyto encrypt a message that only A can decipher with his private-key.

[0010] As described in [3], Marc Branchaud, A SURVEY OF PUBLIC-KEYINFRASTRUCTURES, Department of Computer Science, Mc Gill University,Montreal 1997, page 5, computing with public-key ciphers takes muchlonger than encoding the same message with a secret-key system. This hasled to the practice of encrypting messages with a secret-key system suchas DES and then encoding the secret-key with a public-key system such asRSA. In this case the public-key system securely transports thesecret-key. In case that a message is sent secretly from A to B then,besides a secret-key, which is used optionally, only the key pair of Bis used.

[0011] The described public-key system also allows owner A to sign amessage to be sent to B with a digital signature. In this case the keypair of A is used. A encrypts the message or a corresponding hash of themessage with his private-key which, on the other side of thetransmission channel can be decrypted by B using A's public key. One keypair can therefore be used to receive an encrypted message or to send adigitally signed message.

[0012] B (and any third parties), who can decrypt with A's public-key amessage signed by A, can therefore trust that A has signed the messageas far as D can trust that the selected public-key truly belongs to A.

[0013] In order to ensure that public-keys can systematically bepublished and truly relate to the persons A, B, . . . indicated byattached public-key values, registration- and certification authorities(RA, CA) have been introduced to certify the relationship between agiven key and a claimed identity.

[0014] According to [3], page 10 a public-key infrastructure, in itsmost simple form, is a system for publishing public-key values used inpublic-key cryptography. There are basic operations, namelyregistration, certification and validation, which are common to allpublic-key infrastructures.

[0015] Certification is the means by which registered public-key values,and information pertaining to those values, are published. A basiccertificate therefore contains at least the public-key of the concernedsubject, subject identification information, and identificationinformation of the certifying authority.

[0016] The certificate is signed by the certifying authority with thecertifying authority's private-key and can be validated with thepublicly known public-key of the certifying authority. In other words acertificate is therefore an encyrypted message issued by the certifyingauthority declaring that the therein contained public-key relates to theenclosed subject identification information.

[0017] As described in [3], pages 19-21, authentication is a processprovided by a public-key infrastructure. When a certifying authoritycertifies an entity and a user then validates that certification, theentity is said to have been authenticated.

[0018] The degree to which a user can trust the certificate'sinformation and it's validity is a measure of the strength of theauthentication.

[0019] [4], U.S. Pat. document No. 6,202,151 B1 describes a biometriccertification system and method which implement an end-to-end securitymechanism binding the biometric identification of consumers with digitalcertificates.

[0020] Users can also be authenticated through something possessed suchas a token or a smart card. Tokens are, as described in [1], pages2228-2229, hand-carried devices that are normally intended to increasepassword security by assuring that passwords are used only once, therebyreducing the vulnerability to password compromise. Tokens may containinternally an algorithm, which either works in synchronisation with anidentical algorithm in a host computer or which transform an inputderived from a computer prompt into a password that matches thecomputer-transformed result. In a public-key infrastructure a tokencontaining a private-key may used to sign a message as described above.

[0021] The degree of authentication of a user by means of a token ishowever in many cases not strong enough. A man, to which the token hadbeen assigned, may, rightfully or not, deny at a later stage that thetoken actually belongs to him.

[0022] In order to significantly increase the degree of authentication,in the not yet published European Patent Application No. 01810513.0 itis proposed to register users by means of a token or an other securedevice at an authority, preferably the registration authority of apublic-key infrastructure based on credentials, including signedbiometric data presented to said authority.

[0023] The biometric data are signed by means of a private key issuedindividually by the registration authority automatically for each token.In addition to signing the biometric data with the private key of theregistration authority the data can further be signed with the user'sprivate key contained in the token.

[0024] After registration the token is a secure element of thepublic-key infrastructure allowing to encrypt messages and securely signmessages, with digital signatures, on which a third party can rely on.

[0025] It therefore seems that the basic objectives of encryptionmentioned before, secrecy, authentication, digital signatures andintegrity are achieved by applying the technology described above.

[0026] However the use of public key infrastructures still involvesrisks which are described in [6}, Carl Ellison and Bruce Schneier, TenRisks of PKI: What You're not Being Told about Public KeyInfrastructure, Computer Security Journal, Volume XVI, Number 1, 2000.

[0027] For an institution such as bank institute a first risk i.e.question mentioned in [6] is, whom the institution can trust. Furtherrisks or questions are derivatives of this question asking, whether theinstitute can trust the certification authority or rely on certificationprocesses.

[0028] Important is the question, whether the authenticated person, forexample OLIVIER HOLDER, is actually the person who is presenting thecertificate. With the incorporation of the user's biometric data intothe certification process it can be trusted that OLIVIER HOLDER iscorrectly authenticated. However the question remains whether OLIVIERHOLDER, with whom the institution is connected over a communicationchannel, is actually the man with whom the institution formerlycommunicated or whether it is a different person with the same name. Inthis respect in [6] also the security of the verifying computer isdiscussed. For example an attacker could add his own public key to thelist of public keys maintained in institution, so that he could issuehis own certificates, for example issued on the name of OLIVIER HOLDER,which would be treated exactly like legitimate certificates.

[0029] In view of relating a calling client, such as OLIVIER HOLDER, tothe correct one among one or more clients with the same name, aninstitution normally uses a mapping list (see FIG. 1, 32), which mapsdata retrieved from a certificate to records of a customer database suchas the directory 33 shown in FIG. 1. Besides the question whether thecertificate from which data is used for mapping purposes, a new questionarises, which has not been addressed in [6]. The question is, can theinstitution trust itself? For the bookkeeper of a bank institute itmakes little difference whether a person internal or external to theinstitution is responsible for an illegal transfer of a million dollars.Therefore in case that the institution is perfectly shielded againstexternal attackers it is still possible that the mapping list or thecustomer database has been manipulated by an internal attacker.

[0030] It would therefore be desirable to reduce the described risksthus improving public-key infrastructures.

[0031] It would be desirable in particular to improve overall systemreliability, in particular authentication and data integrity.

[0032] More particularly it would be desirable to provide a method forsecuring relational data based on which business transactions areperformed by an institution which acts according to instructionsreceived by said certificate holder. In fact it would be desirable thatthe institution be removed from as many issues as possible concerningliability within an open, public key infrastructure, so that theinstitution is only responsible for the internal processing and securityof any data belonging or related to its customer and does not need torely on a trusted third party.

[0033] It would further be desirable to achieve the described objectswith practically no significant investments and efforts by theinstitution and the certificate holders.

SUMMARY OF THE INVENTION

[0034] The above and other objects of the present invention are achievedby a method according to claim 1.

[0035] The inventive method allows the securing of data related to usersof a public key infrastructure, who may present certificates at aninstitution in order to initiate transactions. For this purposes theinstitution preferably uses and securely stores a secret key or a keypair which is designed for encrypting and decrypting data.

[0036] Based on a request of a client, who is the holder of acertificate, an institution may allow the certificate holder to basefuture transactions or system access on his certificate. According tosecurity regulations implemented, the institution will preferably verifythat the person who is presenting the certificate is the actual ownerfor whom the certificate had been issued. The institution will furtherverify whether the certificate holder relates to a registered user orcontract holder with the institution, and will demand correspondingproof of this relationship.

[0037] Based on an agreement or a contract closed between a certificateholder and the institution, corresponding relational data are generated.Then said relational data are encrypted preferably with theinstitution's first key of an asymmetric key pair such as aprivate/public key pair.

[0038] Subsequently the encrypted relational data are integrated intothe certificate, which preferably adheres to ITU recommendation X.509version 3. The relational data could be included in the certificate as anon-standard certificate extension.

[0039] At a later stage, whenever the certificate holder contacts theinstitution in order to initiate a transaction based on said agreementbetween the certificate holder and the institution, encrypted relationaldata contained in the certificate is decrypted by means of the secretkey or the second key of said key pair of the institution.

[0040] Since the certificates, into which relational data areintegrated, are elements of the public key infrastructure, otherprocesses provided in this infrastructure are also performed whenever acertificate is presented. In case that an authentication of acertificate holder fails, for example due to expiration of thecertificate, then the inventive method would not be applied.

[0041] The inventive method therefore allows institutions to integraterelational data into the certificate of a certificate holder, in theform of specific attributes defined and recognized by that institution.These institutional attributes are encrypted by the institution and canonly be decrypted by the institution again.

[0042] The encryption and decryption of relational data can be performedby means of a single secret key (see [3], page 4) since the encryptedrelational data corresponds to a message which is written and read bythe same party i.e. the institution only. A transfer of the secret keyacross the network from a sender to receiver is therefore not required.

[0043] However in order to increase security internally in theinstitution a key pair could be used with one key held in a registrationdepartment, where relational data are encrypted, and the other key heldsecurely stored in another department, for example where transactionsare handled. Said keys correspond to a private key and a public key ofthe public key infrastructure although preferably both of these keys arenot published.

[0044] A holder of a certificate opens for example an account at aninstitution, for example a bank, which, based on an agreement of termsregarding said account generates relational data which then isintegrated in encrypted form into the certificate.

[0045] This enables the institution to identify and authenticate acertificate holder in a much stronger fashion than would be possiblewithout the additional institutional attributes. In case that thecertificate passes standard authentication, it is established that thecertificate belongs for example to an OLIVIER HOLDER. Decrypting theencrypted relational data contained in the certificate confirms theidentity of OLIVIER HOLDER, and indicates what relations exist betweenOLIVIER HOLDER and the institution. In case that several persons withthe name HOLDER are registered at the institution, it is simultaneouslyestablished which one of these persons is concerned.

[0046] In order to prevent transfer of encrypted relational data i.e. ofan institutional attribute from an original certificate to a certificateused by an attacker, said encrypted relational data are strongly linkedto the original certificate by means of integrating certificate specificdata into the institutional attribute, so that manipulated certificates,which contain transferred institutional attributes, can be identified.

[0047] The risks described in [6] are therefore significantly reduced byapplying the inventive method.

[0048] In view of [6], Risk#1 (“Who do we trust, and for what?”), trustreceived by the elements of the public key infrastructure are combinedby using the inventive method with the trust the institution has initself. It is important to note that the additional link in the securitychain is not linked serially but in parallel to existing links of thechain. In case that an element of the public key infrastructure failsthen the security chain still holds by means of the inventive measures.

[0049] In case that the institution uses a pair of keys, which aresecurely stored in separate departments then the trust in theinstitution itself can further be increased.

[0050] In view of [6], Risk#4 (“Which JOHN ROBINSON is he?”), it hasbeen explained that among several persons bearing the same name (e.g.OLIVIER HOLDER i.e. JOHN ROBINSON) the correct person can easily beidentified by means of the decrypted relational data, which comprise forexample the client number and further details of the agreement betweenthe institution and the certificate holder or a further institution thecertificate holder is working for. By means of the inventive method theinstitution can therefore reliably answer the extended question “WhichOLIVIER HOLDER is he and what is our relation to this OLIVIER HOLDER?”.

[0051] Since the relational data are encrypted in the certificate athird party or the certificate holder will not have access to thisrelational data. The third party will not even have access to one of thekeys of the institute's key pair. A certificate holder can thereforehave institutional attributes of different institutions integrated inhis certificate and still maintain secrecy, since an institution candecrypt relational data only with the corresponding key.

[0052] The certificate remains therefore open to the public except forencrypted relational data integrated therein.

[0053] In a preferred embodiment of the invention decrypted relationaldata is used to verify data of a calling client which data is stored ina directory of the institution. A mapping list is no longer requiredsince data required e.g. for mapping the name of a client to a clientnumber is already contained in the relational data i.e. theinstitutional attribute. The system on the institute's side is thereforesimplified. A manipulation of the directory can easily be detectedduring the described verification process, so that integrity of data atleast in the used parts of the directory is always established.

[0054] The inventive method therefore allows to significantly improveoverall system reliability, in particular authentication and dataintegrity, by selectively simplifying the open cryptographiccommunications system through selective integration of closed modules.

[0055] In a different embodiment of the invention an institution, suchas a governmental authority, may also integrate relational data into acertificate, which is based on approved information. The institutionconfirms correctness of this information by signing the unencryptedrelational data with the private key of the institution.

[0056] Any third party, particularly the attribute integratingcertification authority, can verify said signature contained in thecertificate by means of the published public key of the institutionwhenever the confirmed information needs to be proven.

[0057] In a preferred embodiment the information may concern the factthat the certificate holder possesses additional certificates. Theinstitutionor an attribute integrating certification authority mayverify and confirm correctness of the additional certificates bygenerating and signing corresponding unencrypted relational data withthe private key of the institution.

[0058] In order to integrate the encrypted or signed relational data inthe certificate said relational data is sent to the concerned authorityof the public key infrastructure which adds the received encrypted orsigned relational data and reissues the certificate.

[0059] The process of generating, encrypting, transmitting andintegrating new relational data into a certificate as well as reissuingand sending the enhanced certificate to the institution and to thecertificate holder can take place during the same session establishedbetween the certificate holder and the institution. The update of thecertificate can therefore automatically be executed in a short timeperiod without any noticeable effort by the concerned parties. Theinsignificant efforts required for updating certificates stand howeverin relation to large efforts required instead for maintaining integrityof data of the institution's databases.

[0060] The certificate is preferably stored in a token which is carriedby the certificate holder. In case that the token comprises a biometricinput device it could be assured that only the certificate holder coulduse the token.

BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Some of the objects and advantages of the present invention havebeen stated, others will appear when the following description isconsidered together with the accompanying drawings, in which:

[0062]FIG. 1 shows a known public key infrastructure operating withconventional certificates;

[0063]FIG. 2 shows a public key infrastructure operating according tothe inventive method and

[0064]FIG. 3 shows a certificate extended with attributes.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0065]FIG. 1 shows a known public key infrastructure operating withconventional certificates. A person, e.g. OLIVIER HOLDER, may apply atan authority 100 of the public key infrastructure for a certificate 11.The authority 100, which over the Internet 200 is connected to terminals20, 30 of users of the public key infrastructure, normally consists of aregistration authority 101, a certification authority 102, a key andcertificate management unit 103 and a database 104 containing thedirectory of the public key infrastructure. The applicant, OLIVIERHOLDER, may use a soft or a hard token 10 a, 10 b, 10 c.

[0066] Credentials submitted to the registration authority 101preferably comprise biometric data which allow strong authentication ofan applicant. An applicant therefore preferably uses a token 10 a whichallows to read biometric data by means of a biometric input device 1. Asdescribed in the European Patent Application No. 01810513.0 biometricdata may be read during registration only or also thereafter for eachtransaction initiated by the certificate holder based on thecertificate.

[0067] The issued certificate 11, which comprises a public key 12 canthen be used as described above or in [3], pages 5-12. OLIVIER HOLDERmay for example present his certificate 11 on-line over the Internet 200at an institution 30, for example a bank institute in order to initiatea transaction such as a transfer of money from his account to an accountof third parties.

[0068] In the known infrastructure the institution 30 needs to trust thecertificate 11 i.e. the certification authority 102 in order toauthenticate OLIVIER HOLDER, the holder of the transmitted certificate11. By means of a map or a mapping list 32 the institute relates theauthenticated person to a record stored in a directory 33, whichcontains the data of the client, OLIVIER HOLDER. In case that thedirectory 33 contains data of different persons with the name OLIVIERHOLDER then the serial number of the certificates 11 may be used for themapping process.

[0069] The risks involved in this procedures have been described above.Institutions 30 may distrust external authorities, such as thecertification authority 102, particularly for transactions concerninglarge amounts of money. In addition institutions 30 should be aware ofrisks within their own premises. As detailed above attackers couldintrude the computer systems of the institutions 30 and manipulate themapping list 32 and/or the directory 33.

[0070]FIG. 2 shows a public key infrastructure operating according tothe inventive method. In the given example the certificate holder,OLIVER HOLDER, uses a token 10 a comprising a biometric input device.Other means, such as a soft token (see FIG. 1, 10c), for storing thecertificate 11 could be used as well.

[0071] As shown in FIG. 2 the certificate held by OLIVIER HOLDER is anextendable certificate 11 such as a certificate specified according toITU recommendation X.509 version 3 which is described in [3], pages40-42.

[0072] According to the present invention an institution 30 may allowthe certificate holder to base future transactions or system access onhis certificate 11. Based on security regulations implemented theinstitution 30 will preferably verify that the person who is presentingthe certificate 11 is the actual owner for whom the certificate 11 hadbeen issued. The institution 30 will further verify whether thecertificate holder relates to a registered user or contract and willdemand corresponding proof. This initial verification can take place ina know manner, e.g. by transferring passwords or keywords taken from alist over a secure channel.

[0073] According to the present invention data relating to the client ofthe institution 30 are securely stored in the certificate 11 thusavoiding the use of a mapping list.

[0074] For this purposes the institution preferably uses and securelystores a secret key or a key pair which is designed for encrypting anddecrypting data. Based on an agreement or a contract closed between theholder of the certificate 11 and the institution 30, correspondingrelational data are generated.

[0075] Then said relational data are encrypted with the institution'ssecret key or the first key 35 of said key pair. Subsequently theencrypted relational data are integrated into the certificate 11.

[0076] In order to integrate the encrypted relational data into thecertificate 11 said encrypted relational data is sent to the authority100 of the public key infrastructure which adds the received data as aninstitutional attribute and reissues the certificate 11. Subsequentlythe certificate is transferred to the certificate holder and preferablyas well to the institution 30.

[0077] The process of generating, encrypting and integrating therelational data as well as reissuing the certificate 11 can performedwithin minutes during a session between a calling certificate holder andthe institution 30.

[0078] At a later stage, whenever the certificate holder contacts theinstitution in order to initiate a transaction based on an agreementbetween the certificate holder and the institution 30, encryptedrelational data is read from the certificate 11, decrypted by means ofthe secret key or the second key 36 of said key pair of the institution30.

[0079] This enables the institution to identify and authenticate acertificate holder much stronger. In case that the certificate passesstandard authentication, it is established that the certificate belongsfor example to a OLIVIER HOLDER. Decrypting the encrypted relationaldata contained in the certificate confirms the identity of OLIVIERHOLDER, and indicates what relations exist between OLIVIER HOLDER andthe institution. In case that several persons with the name HOLDER areregistered at the institution, it is simultaneously established whichone of these persons is concerned.

[0080] In a further step the decrypted relational data is preferablyused to verify data stored in a directory 33 of the institution 30. Amapping list is no longer required since data required for mapping thename of a client to a client number is already contained in therelational data i.e. the institutional attribute.

[0081] The encryption and decryption of relational data by theinstitution 30 can be performed by means of a single secret key (see[3], page 4) since the encrypted relational data corresponds to amessage which is written and read by the same party i.e. the institution30 only and a transfer of the secret key across the network from asender to receiver therefore is not required.

[0082] In order to increase security internally in the institution anasymmetric key pair such as a private/public key pair is preferably usedwith the first key, which for example corresponds to a private key heldin a registration department, where relational data are encrypted, andthe second key, which corresponds to a “public” key, held securelystored in another department, for example where transactions arehandled.

[0083] Although the term public key is used for the second key, thissecond key is preferably securely stored in a department of theinstitution.

[0084] Since the relational data are contained in encrypted form in thecertificate a third party or the certificate holder will not have accessto this relational data. A third party or the certificate holder willnot even have access to one of the keys of the institute's key pair. Acertificate holder can therefore have institutional attributes ofdifferent institutions integrated in his certificate and still maintainsecrecy, since an institution can decrypt relational data only with thecorresponding key.

[0085] In order to prevent transfer of encrypted relational data i.e. ofan institutional attribute from an original certificate to a certificateused by an attacker, said encrypted relational data are preferablystrongly linked to the original certificate by means of integratingcertificate specific data into the institutional attribute, so thatmanipulated certificates, which contain transferred institutionalattributes, can be identified.

[0086] For this purpose the encoded relational data are preferablycombined with a data segment i.e. a certificate identifier, which issuitable to identify the certificate.

[0087] As shown in FIG. 3 preferably the hash of the certificate body,which has been signed by the certification authority 102, is used ascertificate identifier. In order to link the certificate identifier tothe encoded relational data, a hash of the combination of the encodedrelational data and the certificate identifier is built, signed by theinstitution and added to the institutional attribute. When receiving thecertificate at a later stage the institution can easily verify that thecertificate identifier belongs on the one hand to the encryptedrelational data and on the other hand to the presented certificate thusclosing the link between the institutional attribute and the presentedcertificate.

[0088]FIG. 3 shows the certificate 11 extended with three attributes

[0089] 1) the hash of the certificate body signed by the certificationauthority 102,

[0090] 2) a first institutional attribute comprising relational dataencrypted by the institution 30, the, hash of the certificate bodysigned by the certification authority 102 and the hash of thecombination of the encrypted relational data and the hash of thecertificate body, said hash of this combination signed by theinstitution 30 and

[0091] 3) a second institutional attribute comprising relational dataencrypted by the institution 30 and the hash of the combination of theencrypted relational data and the hash of the certificate body, saidhash of this combination signed by the institution 30.

[0092] In the second institutional attribute the hash of the certificatebody is not included since this hash is included in the certificate 11as attribute.

[0093] In a different embodiment of the invention an institution 30,such as a governmental authority, may also integrate relational datainto a certificate 11, which is based on information the institution hasapproved. The institution 30 confirms correctness of this information bysigning the unencrypted relational data with the private key of theinstitution 30.

[0094] Any third party can verify said signature contained in thecertificate by means of the corresponding published public key of theinstitution 30 whenever the confirmed information needs to be proven. Inthis case the institution 30 preferably uses a different key set namelythe key set for which a certificate was issued and published by anauthority 100 of the public key infrastructure.

[0095] In a preferred embodiment the information may concern the factthat the certificate holder possesses additional certificates. Theinstitution 30 which can be the certificate issuing certificationauthority itself, may verify and confirm correctness of the additionalcertificates by signing the resulting unencrypted relational data withthe private key. In order to integrate the signed relational data in thecertificate said relational data is sent to the concerned authority ofthe public key infrastructure which adds the received data and reissuesthe certificate as described above.

[0096] The certificate 11 incorporates in this case two or morecertificates which at least for the institution 30 but also for thirdparties may considerably raise the trust into the certificate 11.

[0097] Although the present invention has been described in detail withreference to preferred embodiments, persons having ordinary skill in theart will appreciate that various modifications and differentimplementations may be made without departing from the spirit and scopeof the invention.

REFERENCES

[0098] [1] Richard C. Dorf, THE ELECTRICAL ENGINEERING HANDBOOK, 2^(nd)Edition, CRC-Press, Boca Raton 1997

[0099] [2] U.S. Pat. document No. 4,405,829 (Rivest et al.)

[0100] [3] Marc Branchaud, A SURVEY OF PUBLIC-KEY INFRASTRUCTURES,Department of Computer Science, Mc Gill University, Montreal 1997

[0101] [4] U.S. Pat. document No. 6,202,151 B1 (Musgrave et al.)

[0102] [5] PKCS#10 Standard, Certification Request Syntax Standard, RSALaboratories May 2000 (available underhttp://www.rsasecurity.con/rsalabs/pkcs/index.html)

[0103] [6] Carl Ellison and Bruce Schneier, Ten Risks of PKI; WhatYou're not Being Told about Public Key Infrastructure, Computer SecurityJournal, Volume XVI, Number 1, Computer Security Institute 2000

[0104] [7] A. Menezes, P. van Oorschot, S. Vanstone, HANDBOOK OF APPLIEDCRYPTOGRAPHY, CRC-Press, Boca Raton 1997

1. Method for securing data relating to users of a public keyinfrastructure who may present certificates (11) at an institution (30)in order to initiate transactions, comprising the steps of a) providingcryptographic means to the institution (30) which are designed forencrypting and decrypting data, b) generating relational data based onan agreement between a certificate holder and the institution (30), c)encrypting the relational data by the institution (30) with saidcryptographic means, d) integrating the encrypted relational data intothe certificate (11) of said certificate holder and e) decrypting saidencrypted relational data contained in the certificate (11) of saidcertificate holder with said cryptographic means whenever a transactionis to be performed based on said agreement between the certificateholder and the institution (30).
 2. Method according to claim 1comprising the steps of a) generating a secret key or a key pair (35,36) which is designed for encrypting and decrypting data and which isused and securely stored by the institution (30), b) generatingrelational data based on an agreement between a certificate holder andthe institution (30), c) encrypting the relational data with the secretkey or the first key of said key pair (35, 36) of the institution (30),d) integrating the encrypted relational data into the certificate (11)of said certificate holder and e) decrypting said encrypted relationaldata contained in the certificate (11) of said certificate holder bymeans of the secret key or the second key of said key pair (35, 36) ofthe institution (30) whenever a transaction is to be performed based onsaid agreement between the certificate holder and the institution (30).3. Method according to claim 1 or 2, comprising the steps of binding therelational data securely to the corresponding certificate and bycombining the encrypted relational data with a certificate identifier,such as the hash of the certificate body, which has been signed by thecertification authority (102).
 4. Method according to claim 3,comprising the steps of building a hash of the combination of theencoded relational data and the certificate identifier and signing tilecombined data by the institution (30).
 5. Method according to one of theclaims 1-4, comprising the steps of sending the encrypted or combinedand signed relational data to the authority (101, 102) of the public keyinfrastructure which has issued the certificate (11), said authority(101, 102) adding the received encrypted relational data to thecertificate (11) and reissuing said certificate (11).
 6. Methodaccording to one of the claims 1-5, comprising the steps of transferringthe reissued certificate (11) which contains the encrypted or signedrelational data to the certificate holder and/or to the institution (30)preferably during the session the encrypted or signed relational datawas received by the authority (101, 102).
 7. Method according to one ofthe claims 1-6, comprising the steps of securely storing the keys (35,36) of the key pair, which are used for encrypting and decryptingrelational data, separated from each other in different locations ordepartments of the institution (30).
 8. Method according to one of theclaims 1-6, comprising the steps of securely storing the secret key,which is used for encrypting and decrypting relational data, at theinstitution (30).
 9. Method according to one of the claims 1-8,comprising the steps of comparing the decrypted relational data withdata stored in a directory (33) of the institution (30) in which data ofclients and relations between the institution (30) and said clients arestored in order to check integrity of said data.
 10. Method according toone of the claims 1-9 comprising the steps of integrating encrypted orsigned relational data in the certificate individually for more than oneagreement or confirmed information.
 11. Method particularly according toone of the claims 1-10 for securing data relating to users of a publickey infrastructure who may present certificates (11) in order to proveinformation corresponding to said data, comprising the steps of a)generating relational data based on information related to a certificateholder, said information being confirmed by the institution (30) by b)securely transferring said relational data to the certificationauthority (102) and c) integrating the signed relational data into thecertificate (11) of said certificate holder.
 12. Method according to oneof the claims 1-11 comprising the steps of generating additionalrelational data based on one or more additional certificates, thecertificate holder has received from other authorities of the public keyinfrastructure, and integrating said additional relational data signedand/or encrypted into the certificate (11).
 13. Method according to oneof the claims 1-12 comprising the steps of storing the certificate (11)in a token (10) which preferably comprises a biometric input device (1).14. Method according to one of the claims 1-13 using an extendablecertificate (11) such as a certificate specified according to ITUrecommendation X.509 version 3.